1. Field of the Invention
The present invention generally relates to a system, method and medium for enabling components to be added to a web page while preserving use of the uniform resource locator (URL) associated therewith and, more particularly, to a system, method and medium for enabling the components to be added by separating the component hierarchy from the parameter hierarchy within and/or utilized by a user interface framework.
2. Background of the Invention
Today's World Wide Web (WWW) sites deliver a wide variety of dynamic, personalized content to end users. Although a variety of technologies exist, such as, for example, component-based web user interface frameworks that facilitate building sophisticated web sites, known technologies and/or frameworks do not provide a solution to the problem of non-addressable URLs that may be caused by one or more changes to a component hierarchy. As used herein, the WWW refers to a system of internet protocol (IP) servers that support documents that are formatted in markup languages such as HyperText Markup Language (HTML), Extensible Markup Language (XML), Wireless Markup Language (WML), or Hand-held Device Markup Language (HDML). The term WWW as used in this specification can also to refer to any server or connected group or interconnected groups of servers that implement a hyperlinking protocol, such as HyperText Transfer Protocol (HTTP) or Wireless Application Protocol (WAP), in support of Uniform Resource Identifiers (URIs) and documents in markup languages, regardless whether such servers or groups of servers are coupled to the WWW as such.
HTTP, the underlying protocol used by the WWW, defines how messages are formatted and transmitted, and what actions Web servers and browsers should take in response to various commands. For example, when a user enters a URL into a browser, this actually sends an HTTP command to the Web server directing it to fetch and transmit the requested Web page.
HTTP is called a stateless protocol because each command is executed independently, without any knowledge of the commands that came before it. This is the main reason that it can be difficult to implement Web sites that react intelligently to user input.
There can thus be problems in developing user interfaces (UIs) for the Web. One such problem is that state management, converting raw HTTP requests state into UI state and vice versa, typically requires substantial manual intervention by the programmer. Programmers thus have to carefully name each state parameter, using knowledge of all the other state parameters in the Web UI, to avoid namespace collisions. As used herein, a namespace is a means of resolving naming conflicts by defining a globally unique name for a particular set of elements.
A second problem associated with developing UIs for the Web, a product of the first, is that Web UI code is generally difficult to reuse. Programmers cannot generally use code from an old UI in a new UI without modifying the code because the code contains custom state management logic. The state management logic is appropriate only to the old UI. Thus, if the code is introduced into a new UI without careful modification, the code can cause namespace collisions.
Web UI frameworks thus need to provide state management, and component UI frameworks need to support composability and reusability. Existing systems, such as Bebop and JavaServer™ Faces (JSF), satisfy these requirements by, for example, utilizing a component framework that can provide URI encoded data that resolves namespace collisions.
FIG. 1, generally at 100, shows an exemplary simplified architecture of JSF. JSF is a server side 103 UI component framework for Java technology based web applications. The current version of the JSF specification is version 1.2, as defined by Java Specification Requests (JSR) 252, which was released for early draft review on Dec. 8, 2004. JSF version 1.2 is incorporated herein by reference.
Client side 101 devices can include devices such as a standard personal computer (PC) 102, a cellular telephone 104, and/or a personal digital assistant (PDA) 106. Server side 103 can include, for example, a standard server 108 computing device. A servlet 124 can run on server 108, and generally serve as an interface or gatekeeper between server side 103 and client side 101. As used herein, a servlet 124 is a web component, managed by a container, that generates dynamic content. Servlets 124 are platform independent Java classes that are compiled to platform neutral bytecode that can be loaded dynamically into and run by a Java enabled web server, such as server 108. Servlets 124 interact with web clients 102, 104, 106 via a request/response paradigm implemented by the servlet container.
JSF page 110 utilizes a regime, such as a tree 114 of UI components, which can be associated with backend model objects called backing beans 122. Backing beans 122 handle application logic (sometimes called business logic). HTML renderer 112 is used to display on PC 102 (and/or similar devices) the data maintained in component tree 114. JSF page 116 also utilizes a component tree 120, which can also be associated with backing beans 122. Wireless Markup Language (WML) renderer 118 is used to display the data maintained in components 120 on wireless devices such as cellular telephone 104 and/or PDA 106.
In JSF, component trees 114 and 120 can thus be used for displaying a structure in which content may be presented on different client types (e.g., PC 102 and cellular telephone 104) using different protocols (e.g., HTML for personal computer 102 and WML for cellular telephone 104). The individual components 126, 128, 130 of component trees 114, 120 are configurable, reusable elements that compose (e.g., are used to render) the user interfaces of JSF applications. Components 126, 128, 130 can be, for example, a table, a frame, and the like.
All code in a UI is encapsulated inside the components (e.g., components 126, 128, 130). Components 126, 128, 130 adhere to the following rules:
1. Each component (e.g., component 126, 128, 130) has a name, unique with respect to its siblings;
2. Each component (e.g., component 126, 128), except for the root component (e.g., component 130), has one parent component;
3. Each component (e.g., component 126, 128, 130) may contain child components; and
4. Each component (e.g., component 126, 128, 130) may contain state parameters.
Rules 2 and 3 place each component in a component hierarchy.
FIG. 2 is an exemplary diagram of a component hierarchy. Each (C) (e.g., 202a-e) represents a component, and each string adjacent to a component in quotes (e.g., “root” 204a, 204b-e, etc.) is a component name. Similarly, each (P) (e.g., 206a-c) represents a parameter, and each string adjacent to a parameter in quotes (e.g., “exampleparam” 208b) is a parameter name. Component trees 114, 120 may assume a form such as shown in FIG. 2.
A component hierarchy such as shown in FIG. 2 can be used to facilitate naming parameters by enabling a set of unique paths to be produced, one for each node. For example, note that FIG. 2 has three parameters named exampleparam: exampleparam 208a, exampleparam 208b, and exampleparam 208c. Ordinarily, having three parameters with the same name would be problematic, because the following illustrative scenario may result when state is marshaled to a URL:                exampleparam=foo        exampleparam=bar        exampleparam=baz        
The situation above result leads to indeterminacy regarding which value belongs to which parameter, and generally results in web page failure or unexpected behavior.
One possible solution that may be implemented to avoid indeterminacy is to utilize the order of the parameters (e.g., foo, bar, and baz are utilized first, second, and third, respectively). However, this approach is not reliable because a fourth exampleparam parameter may be added, for example, between exampleparam 208a and exampleparam 208b, which would change the order of the parameters.
Therefore, instead of utilizing the order of the parameters, a rule can be utilized providing that state parameters are named according to their unique position in the component hierarchy 200. When this rule is utilized in connection with a component hierarchy 200 such as shown in FIG. 2, the names are instead:                root.alpha.kingdom.exampleparam=foo        root.alpha.phylum.exampleparam=bar        root.beta.exampleparam=baz        
There are no namespace collisions, and components can be readily matched with their respective state parameter value.
Thus, as previously discussed, known systems support composability and reusability by utilizing a component hierarchy such as shown in FIG. 2 to resolve namespace collisions. However, while use of a component hierarchy provides state management and supports composability and reusability, use of a component hierarchy also makes it more difficult to enable a Web application to continue to function after changes to the appearance of (e.g., after one or more components are added to a component hierarchy and/or one or more components are deleted from a component hierarchy) the Web application.
FIG. 3, generally at 300, shows an exemplary component hierarchy that is in code form. FIG. 3 can also thus be referred to as a component hierarchy, and generally correspond to (or be derived from) the form of the component hierarchy 200 shown in FIG. 2. In FIG. 3, standard class names (e.g., Java class names) are generally represented as the first word on a line (e.g., Page 302, TabbedPane 304, Pane1 306, TicketDetail 308, etc.), and instances of the class names are generally represented as the second word on a line (e.g., page 320, body, 322, pane1 324, ticketDetail 326, etc.)
Instances of the TabbedPane 304 and Form 312 classes (or components) are stateful, in that a user would expect his decision to “stick.” At any given time, the TabbedPane 304 component shows only one of its child panes. That is, at any given time, TabbedPane 304 will show only one instance of the Pane1 306 or Pane2 310 components. Thus, once Pane1 306 is selected by the user, she expects it to remain selected in subsequent web requests. Similarly, if Pane2 310 (and thus instance pane2 328) is selected by a user, the user will expect Form 312 (and thus instance addTicket 330) to retains its values so that inputs provided by the user (using the respective subject 332, description 334, and discoveryDate 336 instances of the TextInput 314, TextArea 316, and DateInput 318 components) in one request may be processed in a subsequent request.
One known way of retaining state, as is shown in FIG. 2, is to define components such that they directly contain state parameters. Thus, with regard to FIG. 3, the body 322 instance of TabbedPane 304 class can contain state data indicating the currently selected pane (e.g., Pane1 306 or Pane2 310). Now, suppose Pane2 310 is selected. In this case, the addTicket 330 instance of Form 312 can include state information pertaining to data entered for the subject 332, description 334, and discoveryDate 336 instances.
FIG. 4, generally at 400, shows a form (or, grammar) of Pane2 310 that serves as a key to qualify, for example, a currently selected pane (e.g., pane2 308). A web application state is typically encoded into the “query string” portion of a URL. A web URL usually takes the form:
SCHEME+“://”+“HOST”+“/”+“APP”+“?”+QUERY-STRING
Examples utilizing the web URL form are as follows:                https://mit.edu/login?name=john        http://redhat.com/news?date=yesterday&numitems=12        
The query string portion is made up of key-value pairs, or “query variables.” A single key-value pair can be rendered as follows:
KEY+“=”+VALUE
Examples of a key-value pair are as follows:                name=john        numItems=12        
A query string can contain multiple query variables, joined using the ampersand (or, alternately, semicolon) character:
VAR1+“&”+VAR2+“&”+VAR3
Examples of a query string are as follows:                name=john&numItems=12        date=yesterday&id=23&enabled=true        
When a component hierarchy, such as shown in FIG. 3, is utilized to namespace component parameters to prevent collisions, a key to qualify the currently selected pane (e.g., pane2 310) can take the form as shown in FIG. 4. With regard to key 402, the instances of page 320, body 322, pane2 328 and addTicket 330, and the query string subject=Example+ticket 404, will appear in URLs, which can be bookmarked by a user. Thus, in existing UI frameworks, any changes to the component hierarchy 300 that impact the generation of keys, such as key 402, will break those URLs if one or more components are added to and/or deleted from the component hierarchy. That is, the URLs will no longer go to the place the user bookmarked. A good implementation that utilizes this pattern to generate URLs will endeavor to “fail gracefully,” whereas a bad implementation may simply error out. In either case, URLs captured from such an application are not safe to use as are, for example, URLs that are persistent.
FIGS. 5 and 6, taken together, show how a bookmark can default to a home page after a change is made to a component hierarchy associated with a bookmark deep within a website. In particular, FIG. 5, generally at 500, is a screen display associated with a deep bookmark, and FIG. 6, generally at 600, is a screen display showing how the bookmark defaults to the home page of the website when the bookmark of FIG. 5 is accessed subsequent to a change in the component hierarchy of FIG. 5. As used herein, a deep bookmark is a bookmark associated with a domain name that refers to a page other than the home page.
Turning now to FIG. 5, suppose a person visits a web site, encounters a piece of content, and adds the content to her bookmarks folder. Thus, suppose a person bookmarks 502 the webpage shown in FIG. 5. Some time later, she clicks on the bookmark 502 to return to the content. If the structure of the webpage 500 shown in FIG. 5 has changed (e.g., one or more components have been added and/or one or more components have been deleted to the webpage shown in FIG. 5) subsequent to the bookmark, then, instead of having FIG. 5 displayed, the home page 600 may be displayed, as shown in FIG. 6. URL 602 shown in FIG. 6 is accordingly different than the bookmarked URL 502 that the user bookmarked in connection with FIG. 5. This scenario assumes that the components used for the web site generally have “default” failure mode states that they can use to render themselves, such that stateful components beneath the point of change in the component hierarchy can revert to their default states. A more severe case of failure would be that the user simply receives a File Not Found error, without being directed to the homepage.
FIG. 7, generally at 700, is an exemplary illustration of how an existing URL would be broken when a new component is added to a component hierarchy. Component hierarchy 710 is an existing hierarchy, and component hierarchy 720 is a hierarchy after a new browser 704 instance of a BrowserPane 702 class has been added to component hierarchy 710. A user's bookmark corresponding to component hierarchy 710 will contain the state parameter:                page.body.selectedPane=pane2        
When a browser 704 instance of the BrowserPane 702 class is added to component hierarchy 710, thus resulting in component hierarchy 720, the page.body.selectedPane=pane2 state parameter no longer holds its meaning. Instead, the state parameter required is now:                page.browser.body.selectedPane=pane2        
Thus, a component hierarchy can be utilized to avoid namespace collisions. However, the use of a component hierarchy to avoid namespace collisions can lead to another problem. Namely, as a result of adding one or more components to and/or deleting one or more components from the component hierarchy (e.g., adding a browser 704 instance to hierarchy 710, thus resulting in hierarchy 720), the user's bookmark associated with the state parameter associated with the initial component hierarchy no longer works (e.g., the user's bookmark associated with component hierarchy 710 no longer works after browser 704 is added).
At least one embodiment of the present invention is directed to preserving state when one or more components are added to and/or one or more components are deleted from a component hierarchy, and making web UI code easier to reuse by, for example, modeling state data associated with components in a hierarchy that is separate and distinct from the component hierarchy.